Wireless pico-networks are a technology designed to replace the interconnection cables of a fixed or mobile assembly of devices locally linked in a typical ray path, normally of approximately 10 m or even more. As an illustrative example, the devices with pico-networks include a workstation along with peripherals, such as a keyboard, a mouse, and a printer. Other pico-network devices can include a personal digital assistant (PDA), a mobile telephone, audio and video equipment, a server, and more.
Governing an increasing number of electronic hardware manufacturers, the Bluetooth protocol is currently considered the universal platform for wireless pico-networks, allowing transparent communication between many different types of office, personal, household, and institutional devices. Furthermore, its development is directed at functionalities, such as securing transactions, and goes well beyond simply establishing communication of devices grouped within a single vicinity.
As indicated in FIG. 1, the Bluetooth protocol is based on a stack of protocol layers 2, whose lowest layer 4, called the radio layer, constitutes the connection interface that allows bidirectional wireless communication using an antenna 6. Above this layer are then found the baseband layer 8 and a link management protocol layer 10 (known as “link manager protocol” or “LMP”). These two layers 8 and 10 are essentially used to establish and control the links between the various Bluetooth devices. The three above-mentioned layers 4, 8, and 10 are generally implemented in the form of hardware or firmware.
Above the link management protocol layer 10 is the host controller layer 12 (“host controller” or HCL) required for the interface between the Bluetooth hardware elements and the upper protocol 14 (called “logical link control and adaptation protocol” or L2CAP). The host controller 12 is only necessary when the upper protocol 14 resides in a host as software. If the Bluetooth module itself includes an L2CAP layer, this upper layer 14 may no longer be necessary because the resident L2CAP layer would then be able to communicate directly with the LMP 10 and baseband 8 layers.
The applications 16 reside above the L2CAP layer 14 and communicate with it through an adapted software layer 18 (TCS, SDP, RFCOMM, and more.)
The baseband layer 8 includes, in particular, the address and security elements of the communicating device. Among these elements, there is the unique address of the device, called BD_ADD (or BD_Address) in the Bluetooth standard, through which the device can be called and identified in the pico-network. The uniqueness of this address is guaranteed by the IEEE (Institute of Electrical and Electronic Engineers) organization, which assigns communicating device manufacturers part of the specific address for each physical device placed in circulation.
The BD_ADD address of the Bluetooth protocol is presented in the form of a 48-bit binary word, in which 24 bits are provided by IEEE and constitute, for a given manufacturer, a unique portion of addresses, from which each device placed in circulation can be singled out using an additional 24 bits.
Overall, a BD_ADD Bluetooth address is divided into the following: i) a lower 24-bit portion, called LAP, ii) a non-significant portion of 16 bits called NAP, and iii) an upper 8-bit portion called UAP.
At the radio 4 layer and/or baseband 8 layer level, among other things, a series of tests, and if necessary, calibration of radio frequency circuits must be performed to ensure that they comply correctly with the required characteristics for the reception and transmission modes.
FIG. 2 represents, in the form of a flowchart, the elements that normally intervene in the service activation phase of a communicating device 1 equipped with a Bluetooth wireless interface 2.
The service activation includes a writing phase, into the device, of its unique BD_ADD address. This writing operation is done either in postproduction or during production, but at a final stage, in particular, the stage in which each device is tested individually. Indeed, given that this BD_ADD address is, by its nature, different for each device 1, its writing cannot be done through a common manufacturing process. Therefore, an electrically programmable memory 20 resident in the device 1 is used for this purpose. This memory is normally an EEPROM (Electrically Erasable Programmable Read Only Memory)-type memory as in the case illustrated, or a “Flash”-type memory. This memory 20 can also be used, depending on the applications, for storing other non-volatile data relative to the functionalities of the device 1, for example, encryption/decryption data in the form of a key.
All the data to be written into the electrically programmable memory 20 is provided by an external BD_ADD address programming unit 22 that is functionally linked to the Bluetooth device 1 using a communications link L1 during service activation. As a variant, this EEPROM memory 20 can be programmed outside the device and inserted into the device at a later stage. The programming unit 22 integrates, in particular, the sequence of BD_ADD addresses that will then be written into the programmable memory 20 of each device.
Another stage in the service activation of the device 1 includes tests, and if necessary, calibration of radio frequency circuits at the radio layer 4 level. For this stage, an external unit 24 is used, called test/calibration equipment herein, which establishes a first link L2 with the Bluetooth device using a radio frequency cable. The data exchanged by this cable can be used to determine the characteristics of the radio circuit signals, in particular, critical parameters that influence the communication (exact frequency, transmission power, sensitivity, and more.) and that are subject to possible variances in production or that must be individualized.
The test/calibration equipment 24 is also linked, on the one hand, to logical command inputs of the radio circuits 4 (digital link L3) and, on the other, to a second memory 30 designed to save the test data. Normally, this memory 30 is also an EEPROM-type memory and can be presented as an external part that can be inserted into the Bluetooth device 1. This memory 30 receives, for writing, the validation and/or calibration data, as well as other corrections sent by the equipment 24 according to the analysis of the critical communication parameters. In the simplest case, the internal memory 30 does not store the calibration data. It only stores the data that indicates whether the tests were passed successfully, possibly including a certificate, test conditions, and more. This is, in particular, the case when the manufacturing variations are sufficiently narrow so that the specifications are systematically respected if the radio circuits work. The tests are designed to detect malfunctions. If there are significant individual variations, or the specifications are very strict, calibration values can be written into the memory 30. These values are then exploited during the operation of the device 1. As such, the latter will ensure a correct communication despite any manufacturing differences in its characteristics, and will remain in compliance with respect to any adaptations of the foreseen application.
The above description of device communication although useful, it requires extensive use of memory resources. Accordingly, what is need is a solution to provide a better use of the memory resources and of the data integration when the communicating device is placed into service.